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ABSTRACT:  This  paper  details  the  validation  of  a  comprehensive  teaching 
model  for  security  requirements  engineering  which  ensures  that  security  is  built 
into  the  software  from  its  inception.  It  centers  on  the  employment  of  the 
SQUARE  method  for  secure  software  requirements  engineering,  which  was  de¬ 
veloped  at  Carnegie  Mellon  University.  The  effectiveness  of  the  SQUARE 
method,  its  learning  system  and  the  initial  results  of  using  it  in  student  case  stud¬ 
ies  and  in  a  practical,  higher  education  classroom  application  are  reported. 
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INTRODUCTION 

The  software  that  underpins  critical  infrastructure  has  to  be  secure.  Yet,  the  prob¬ 
lem  is  that  historically  it  has  been  almost  impossible  to  build  secure  software.  As 
a  result,  it  is  estimated  that  the  exploitation  of  unsecured  software  costs  the  U.S. 
economy  an  average  of  $60  billion  dollars  per  year  [1]. 

Notwithstanding  the  importance  of  financial  loss  however,  the  real  concern  lies 
in  the  fact  that  the  exploitation  of  a  flaw  in  the  software  that  underlies  basic  in¬ 
frastructure  services  like  power  and  communication  could  cause  a  significant 
disaster  [2],  The  U.S.  Critical  Infrastructure  Taskforce  sums  up  that  likelihood  in 
a  single  statement:  “A  digital  disaster  strikes  some  enterprise  every  day,  [and] 
infrastructure  disruptions  have  cascading  impacts,  multiplying  their  cyber  and 
physical  effects”  [3,  p.  6]. 

Because  of  the  key  importance  of  practitioners  trained  in  secure  software,  The 
National  Strategy  to  Secure  Cyberspace  -  Action/  Recommendation  2-14  has 
mandated  the  Department  of  Homeland  Security  (DHS)  to  “promulgate  best 
practices  and  methodologies  that  promote  integrity,  security,  and  reliability  in 
software  code  development,  including  processes  and  procedures  that  diminish 
the  possibilities  of  erroneous  code,  malicious  code,  or  trap  doors  that  could  be 
introduced  during  development”  [4,  p.  35]. 

The  global  solution  is  to  ensure  that  secure  practice  is  being  followed  in  all  as¬ 
pects  of  traditional  lifecycle  work.  However  in  order  to  realize  this  goal,  it  is 
essential  to  educate  the  professional  community  in  the  particular  concepts  and 
methods  of  secure  practice.  Thus,  it  is  important  to  develop  targeted  content  and 


www.sei.cmu.edu 


Report  Documentation  Page 


Form  Approved 
OMB  No.  0704-0188 
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focused  instruction  that  will  both  ensure  the  proper  understanding  of  secure 
software  engineering  practice,  as  well  as  reinforce  its  importance  to  software 
engineering  students. 

It  would  seem  to  be  a  simple  task  to  “identify  the  necessary  workforce  compe¬ 
tencies,  leverage  sound  practices,  and  guide  curriculum  development  for  educa¬ 
tion  and  training  relevant  to  software  assurance”  [5,  p.  xiv].  However,  the  prob¬ 
lem  is  that  security  is  not  a  mature  field,  and  so  the  teaching  of  security  topics  is 
done  in  a  number  of  disjointed  places  within  higher  education.  That  includes 
“software  engineering,  systems  engineering,  information  systems  security  engi¬ 
neering,  safety,  security,  testing,  information  assurance,  and  project  manage¬ 
ment”  [5,  p.  xiv]. 

Coherent  knowledge  about  “software  assurance  processes  and  practices  has  yet 
to  be  integrated  into  the  body  of  knowledge  of  the  contributing  disciplines”  [5,  p. 
xiv].  Too  often,  the  result  of  this  lack  of  integration  is  the  graduation  of  a  soft¬ 
ware  engineering  student  who  develops  buggy  code  with  weak  security 
measures. 

It  is  both  impractical  and  impossible  to  simply  drop  the  whole  body  of  software 
assurance  knowledge  into  a  traditional  computer  curriculum. 

Therefore  it  seems  important  to  adopt  a  focused  strategy  and  a  clear  starting 
point.  One  of  the  logical  places  to  begin  the  integration  process  is  in  an  area  that 
is  vital  to  good  security  practice,  but  which  is  also  well  established  and  important 
to  general  development.  That  is  security  requirements  engineering. 


THE  IMPORTANCE  OF  REQUIREMENTS  ENGINEERING 

It  is  well  recognized  that  requirements  engineering  is  critical  to  the  success  of 
any  major  development  project  [6,  7,  8,  9,  10].  Several  authoritative  studies  have 
shown  that  requirements  engineering  defects  cost  10  to  200  times  as  much  to 
correct  once  fielded  than  if  they  were  detected  during  requirements  development 
[11].  Other  studies  have  shown  that  reworking  requirements  defects  on  most 
software  development  projects  costs  40  to  50  percent  of  total  project  effort,  and 
the  percentage  of  defects  originating  during  requirements  engineering  is  estimat¬ 
ed  at  more  than  50  percent  [12,  13],  The  total  percentage  of  project  budget  due  to 
requirements  defects  is  25  to  40  percent  [12,  13]. 

Microsoft  has  indicated  that  versions  of  Windows  developed  after  the  Microsoft 
Security  “Push”  have  half  the  patch  levels  of  earlier  versions  of  Windows,  an 
obvious  savings.  Other  recent  industry  data  suggests  that  vulnerabilities  cost  up 
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to  100  times  less  to  correct  when  they  are  found  during  security  requirements 
engineering,  rather  than  after  a  system  is  operational.  Thus  the  costs  of  poor  se¬ 
curity  requirements  show  that  even  a  small  improvement  in  this  area  would  pro¬ 
vide  a  high  value.  By  the  time  that  an  application  is  fielded  and  in  its  operational 
environment,  it  is  very  difficult  and  expensive  to  significantly  improve  its  Securi¬ 
ty- 

According  to  an  overwhelming  number  of  studies  [6,  7,  8,  11,  12,  14,  15,  to 
name  a  few],  requirements  problems  are  the  number  one  cause  of  why  projects 

•  are  significantly  over  budget 

•  are  significantly  past  schedule 

•  have  significantly  reduced  scope 

•  deliver  poor-quality  applications 

•  are  not  significantly  used  once  delivered 

•  are  cancelled 


THE  PROBLEM  WITH  DEVELOPING  SECURITY  REQUIREMENTS 

Security  requirements  are  often  identified  during  the  system  life  cycle.  However, 
the  requirements  tend  to  be  general  mechanisms  selected  from  standard  lists, 
such  as  password  protection,  firewalls,  and  virus  detection  tools.  Often  the  secu¬ 
rity  requirements  are  developed  independently  of  the  rest  of  the  requirements 
engineering  activity  and  hence  are  not  integrated  into  the  mainstream  of  the  re¬ 
quirements  activities.  As  a  result,  security  requirements  that  are  specific  to  the 
system  and  that  provide  for  protection  of  essential  services  and  assets  are  often 
neglected. 

In  reviewing  requirements  documents,  we  typically  find  that  security  require¬ 
ments,  when  they  exist,  are  in  a  section  by  themselves  and  have  been  copied 
from  a  generic  set  of  security  requirements.  The  requirements  elicitation  and 
analysis  that  is  needed  to  get  a  better  set  of  security  requirements  seldom  takes 
place. 

Much  of  the  study  of  requirements  engineering  research  and  practice  has  ad¬ 
dressed  the  capabilities  that  the  system  will  provide.  So  a  lot  of  attention  is  given 
to  the  functionality  of  the  system,  from  the  user’s  perspective,  but  little  attention 
is  given  to  what  the  system  should  not  do.  For  instance,  in  one  discussion  on 
requirements  prioritization  for  a  specific  large  system,  ease  of  use  was  assigned  a 
higher  priority  than  security  requirements. 
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A  key  problem  is  that,  if  security  requirements  are  not  effectively  defined,  the 
resulting  system  cannot  be  effectively  evaluated  for  success  or  failure  prior  to 
implementation.  Security  requirements  are  often  missing  in  the  requirements 
elicitation  process  and  tend  to  be  neglected  subsequently.  In  addition  to  employ¬ 
ing  applicable  software  engineering  techniques,  the  organization  must  under¬ 
stand  how  to  incorporate  the  techniques  into  its  existing  software  development 
processes  [16].  That  is  the  reason  to  embed  security  requirements  instruction  into 
general  courses  in  requirements  elicitation  and  documentation.  The  question  is, 
“how  best  to  do  that”. 


INTEGRATING  SECURITY  REQUIREMENTS  INTO  STANDARD 
CURRICULA 

A  number  of  approaches  can  be  used  for  integrating  security  requirements  into 
standard  curricula.  At  the  National  Institute  of  Informatics  in  Japan,  the  Top  SE 
program  [17]  includes  security  requirements  engineering  as  part  of  its  curricu¬ 
lum.  The  Top  SE  program  includes  discussion  of  misuse  cases,  TROPOS  [18], 
and  goal-driven  requirements  engineering  (KAOS)  [19].  In  addition  there  is  a 
case  study  based  on  the  Common  Criteria. 

Case  studies  for  security  requirements  engineering  and  security  engineering  in 
general  have  been  used  at  the  International  Institute  of  Information  Technology, 
Hyderabad  [20]  as  a  means  of  bridging  the  industry/university  gap. 

The  CERT  program  at  the  Software  Engineering  Institute  has,  over  three  aca¬ 
demic  semesters,  experimented  with  a  novel  technique  to  educate  students  on  the 
development  of  security  requirements  engineering  for  software  systems  [9] . 

This  paper  reports  the  findings  of  a  couple  of  studies  designed  to  validate  a  com¬ 
prehensive  teaching  model  for  requirements  definition,  which  ensures  that  secu¬ 
rity  is  built  into  the  software  from  its  inception.  It  centers  on  the  employment  of 
the  SQUARE  method  of  secure  software  requirements  definition,  which  was 
developed  at  Camegie-Mellon  University.  The  effectiveness  of  the  SQUARE 
method,  its  learning  system  and  the  initial  results  of  using  it  in  a  practical,  higher 
education  classroom  application  will  be  reported. 


CASE  STUDY  ONE:  INTEGRATING  SECURITY  REQUIREMENTS 
INTO  SWE  CURRICULA 

The  motivation  behind  SQUARE  is  to  see  whether  good  requirements  engineer¬ 
ing  processes  can  be  adapted  specifically  to  the  problem  of  identifying  security 
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requirements.  If  this  can  be  done  successfully,  organizations  will  have  the  ability 
to  identify  security  requirements  up  front  rather  than  as  an  afterthought.  The 
SQUARE  process  provides  a  means  for  eliciting,  categorizing,  and  prioritizing 
security  requirements  for  information  technology  systems  and  applications.  Note 
that  while  there  is  nothing  unique  about  the  steps  in  the  process,  which  have  ex¬ 
isted  for  many  years  in  requirements  engineering,  we  have  seen  relatively  little 
evidence  of  their  application  to  security  requirements,  and  even  less  on  whether 
such  a  process  is  successful  for  developing  security  requirements. 

The  existing  methods  fit  nicely  into  the  SQUARE  process.  These  include  misuse 
and  abuse  cases,  attack  trees,  and  formal  methods.  Others,  such  as  the  Common 
Criteria  and  SCR,  suggest  their  own  requirements  engineering  process.  The 
SQUARE  methodology  seeks  to  build  security  concepts  into  the  early  stages  of 
the  development  life  cycle.  The  model  may  also  be  useful  for  documenting  and 
analyzing  the  security  aspects  of  fielded  systems  and  could  be  used  to  steer  fu¬ 
ture  improvements  and  modifications  to  these  systems.  The  process  is  best  ap¬ 
plied  by  the  project’s  requirements  engineers  and  security  experts  in  the  context 
of  supportive  executive  management  and  stakeholders.  We  believe  the  process 
works  best  when  elicitation  occurs  after  risk  assessment  (Step  4)  has  been  done 
and  when  security  requirements  are  specified  prior  to  critical  architecture  and 
design  decisions.  Thus,  critical  business  risks  will  be  considered  in  the  develop¬ 
ment  of  the  security  requirements.  The  SQUARE  steps  are  summarized  below.  A 
detailed  discussion  of  SQUARE  and  how  to  apply  it  can  be  found  in  [21]. 

1 .  Agree  on  Definitions,  is  needed  as  a  prerequisite  to  security  requirements 
engineering.  On  a  given  project,  team  members  will  tend  to  have  definitions 
in  mind,  based  on  their  prior  experience,  but  those  definitions  will  not  nec¬ 
essarily  agree  [22].  For  example,  to  some  government  organizations,  securi¬ 
ty  has  to  do  with  access  based  on  security  clearance  levels,  whereas  to  oth¬ 
ers  security  may  have  to  do  with  physical  security  or  cyber  security.  It  is 
not  necessary  to  invent  definitions.  Most  likely,  sources  such  as  IEEE  and 
SWEBOK  will  provide  a  range  of  definitions  to  select  from  or  tailor.  A  fo¬ 
cus  group  meeting  with  the  interested  parties  will  most  likely  allow  a  con¬ 
sistent  set  of  definitions  to  be  selected  for  the  security  requirements  activity. 

2.  Identify  Assets  and  Security  Goals  -  this  step  should  be  done  at  the  level 
of  the  organization  and  is  needed  to  develop  the  information  system.  This 
provides  a  consistency  check  with  the  organization’s  policies  and  opera¬ 
tional  security  environment.  Different  stakeholders  will  likely  have  differ¬ 
ent  ideas  about  which  assets  are  important  and  the  associated  security  goals. 
For  example,  a  stakeholder  in  human  resources  may  be  concerned  about 
maintaining  the  confidentiality  of  personnel  records,  whereas  a  stakeholder 
in  a  financial  area  may  be  concerned  with  ensuring  that  financial  data  is  not 
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accessed  or  modified  without  authorization.  It  is  important  to  have  a  repre¬ 
sentative  set  of  stakeholders,  including  those  with  operational  expertise. 
Once  the  assets  and  goals  of  the  various  stakeholders  have  been  identified, 
the  goals  will  need  to  be  prioritized.  In  the  absence  of  consensus,  an  execu¬ 
tive  decision  may  be  needed  to  prioritize  these  goals. 

3.  Develop  Artifacts,  is  necessary  to  support  all  the  subsequent  activities.  It  is 
often  the  case  that  organizations  do  not  have  a  documented  concept  of  op¬ 
erations  for  a  project,  succinctly  stated  project  goals,  documented  normal 
usage  and  threat  scenarios,  misuse  cases,  and  other  documents  needed  to 
support  requirements  definition.  This  means  that  either  the  entire  require¬ 
ments  process  is  built  on  a  foundation  of  sand,  or  a  lot  of  time  is  spent 
backtracking  to  try  to  obtain  such  documentation. 

4.  Perform  Risk  Assessment,  requires  an  expert  in  risk  assessment  methods, 
the  support  of  the  stakeholders,  and  the  support  of  a  requirements  engineer. 
There  are  a  number  of  risk  assessment  methods  available.  A  specific  meth¬ 
od  can  be  recommended  by  the  risk  assessment  expert,  based  on  the  needs 
of  the  organization.  The  artifacts  from  Step  3  provide  the  input  to  the  risk 
assessment  process.  The  outcomes  of  the  risk  assessment  can  help  in  identi¬ 
fying  the  high-priority  security  exposures.  Organizations  that  do  not  per¬ 
form  risk  assessment  typically  do  not  have  a  logical  approach  to  consider 
organizational  risk  when  identifying  security  requirements  but  tend  to  select 
mechanisms,  such  as  encryption,  without  really  understanding  the  problem 
that  is  being  solved. 

5.  Select  Elicitation  Technique,  becomes  important  when  there  are  several 
classes  of  stakeholders.  A  more  formal  elicitation  technique,  such  as  JAD 
or  structured  interviews,  can  be  effective  in  overcoming  communication  is¬ 
sues  when  there  are  stakeholders  with  different  cultural  backgrounds.  In 
other  cases,  elicitation  may  simply  consist  of  sitting  down  with  a  primary 
stakeholder  to  try  to  understand  that  stakeholder’s  security  requirements 
needs. 

6.  Elicit  Security  Requirements,  is  the  actual  elicitation  process  using  the 
selected  technique.  Most  elicitation  techniques  provide  detailed  guidance 
on  how  to  perform  elicitation.  This  builds  on  the  artifacts  that  were  devel¬ 
oped  in  earlier  steps,  such  as  misuse  and  abuse  cases,  attack  trees,  threat 
scenarios,  etc. 

7.  Categorize  Requirements,  allows  the  requirements  engineer  to  distinguish 
among  essential  requirements,  goals  (desired  requirements),  and  architec¬ 
tural  constraints  that  may  be  present.  Requirements  that  are  actually  con¬ 
straints  typically  occur  when  specific  system  architecture  has  been  chosen 
prior  to  the  requirements  process.  This  is  good,  as  it  allows  assessment  of 
the  risks  associated  with  these  constraints.  This  categorization  also  helps  in 
the  prioritization  activity  that  follows. 
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8.  Prioritize  Requirements,  depends  not  only  on  the  prior  step,  but  may  also 
suggest  performing  a  cost/benefit  analysis  in  order  to  determine  which  se¬ 
curity  requirements  have  a  high  payoff  relative  to  their  cost. 

9.  Inspect  Requirements,  can  be  done  at  varying  levels  of  formality,  from 
Fagan  Inspections  to  peer  reviews.  Once  inspection  is  complete,  the  organi¬ 
zation  should  have  an  initial  set  of  prioritized  security  requirements.  It 
should  also  understand  which  areas  are  incomplete  and  must  be  revisited 
later.  Finally,  the  organization  should  understand  which  areas  are  dependent 
on  specific  architectures  and  implementations,  and  expect  to  revisit  those  as 
well. 

In  student  team  projects  over  three  separate  semesters,  thirteen  students  gained 
hands-on  experience  through  case  applications  involving  real-world  software 
development  projects.  Using  SQUARE  [21],  the  students  were  able  to  under¬ 
stand  the  importance  of  security  requirements  in  software  systems,  as  well  as 
improve  the  security  foundations  of  the  client  projects  with  which  they  worked. 

The  students  had  a  variety  of  backgrounds  in  our  academic  case  study  group. 
Some  had  background  in  security  and  some  had  background  in  software  engi¬ 
neering  or  information  technology.  However,  none  of  the  students  had  experi¬ 
ence  in  eliciting  and  documenting  security  requirements  for  software  systems. 
They  also  did  not  have  experience  working  with  software  engineering  methods, 
such  as  SQUARE.  The  students  had  to  develop  two  products  to  complete  their 
course  requirements:  (1)  a  document  that  was  delivered  to  the  client  proposing 
security  requirements  and  supporting  artifacts  for  the  client’s  project  and  (2)  a 
process  document  delivered  only  to  the  faculty  advisor.  This  second  document 
discussed  how  the  students  went  about  applying  each  step  in  the  process,  wheth¬ 
er  it  was  easy  or  difficult  to  apply,  and  how  it  could  be  improved  on.  To  that  end, 
the  project  provided  them  with  a  unique  learning  opportunity.  The  following 
student  feedback  shows  how  the  SQUARE  experience  helped  them  later  on  in 
the  workforce: 

Student  1:  “The  real-world  experience  I  gained  from  the  SQUARE  project  gave 
me  the  perfect  set  of  information  security  project  management  and  budgeting 
skills  that  were  invaluable  in  my  job.” 

Student  2:  “While  working  on  the  SQUARE  project  with  Dr.  Mead,  I  took  part 
in  several  in-depth  case  studies  involving  organizations  of  varying  size  and  repu¬ 
tation.  It  was  a  wonderful  opportunity  to  get  a  feel  for  how  real  companies  de¬ 
velop  and  manage  large  IT  projects.  This  insight,  along  with  the  security  focus  of 
SQUARE,  allowed  me  to  hit  the  ground  running  here  with  the  security  projects 
we’re  developing.  Overall  it  was  an  extremely  valuable  experience  and  I’m 
grateful  that  I  was  involved.” 
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CASE  STUDY  TWO:  ASSESSMENT  OF  INCREASE  IN  SECURITY 
KNOWLEDGE 

The  SQUARE  methodology  was  presented  to  students  in  a  basic,  graduate  soft¬ 
ware  engineering  requirements  modeling  class.  The  class  format  is  basically 
stand-up  lectures  with  student  projects.  The  study  involved  two  groups  of  stu¬ 
dents.  The  participants  were  all  graduate  students  in  a  software  engineering  man¬ 
agement  program  at  University  of  Detroit  Mercy,  as  described  in  [23].  These 
were  all  advanced  students.  Most  of  them  had  had  the  software  management 
core,  with  the  exception  of  the  specification  class.  That  core  is  comprised  of  pro¬ 
ject  management,  software  processes,  object  modeling,  and  a  testing  and  assur¬ 
ance  class. 

The  students  all  had  an  acceptable  amount  of  academic  background  in  under¬ 
graduate  software  engineering,  information  systems,  or  professional  IT  work. 
The  students  in  the  sample  groups  were  formed  from  classes  that  were  part  of  the 
regularly  scheduled  curriculum.  The  groups  sampled  comprised  both  fall  and 
winter  offerings  of  these  two.  Because  class  sizes  varied,  the  actual  number  of 
students  in  the  groups  also  varied.  However,  the  number  was  uniformly  compa¬ 
rable  within  each  course.  Thus,  the  individual  group  sizes  were  between  12  and 
1 5  for  the  treatment. 

One  group  was  given  the  security  requirements  engineering  and  SQUARE  prep¬ 
aration.  This  consisted  of  four  lectures  as  follows:  A  general  introduction  to  se¬ 
curity  requirements  engineering,  An  overview  of  the  SQUARE  method  and 
steps,  Detailed  discussion  of  SQUARE  steps  1-4,  and  Detailed  discussion  of 
SQUARE  steps  5-9.  These  lectures  are  available  for  download  from  the  CERT 
website  (http://www.cert.org/sse/square.html).  The  control  group  was  given  the 
normal  set  of  lectures,  which  are  based  on  the  contents  of  IEEE  Standard  830- 
1993  IEEE  Recommended  Practice  for  Software  Requirements  Specifications 
[24]. 

Each  group  was  given  a  pretest  of  knowledge  involving  9  multiple  choice  ques¬ 
tions  (in  Appendix  A).  Then,  following  the  administration  of  the  SQUARE  prep¬ 
aration  the  same  two  groups  were  given  a  post-test  containing  the  same  questions 
and  their  products.  The  results  were  then  subjected  to  a  Student  t 
http://en.  wikipedia. org/wiki/Student's_t-distribution  in  order  to  determine 
whether  the  SQUARE  lectures  led  to  an  increased  capability  in  security  require¬ 
ments  definition. 

Table  1  displays  the  results  of  that  analysis  for  both  groups.  In  Table  1,  df  is  de¬ 
grees  of  freedom,  p- value  is  probability  of  significance,  t  is  student  t  value: 
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Table  1:  Analysis  ofPre  and  Post  Test  Results  for  Control  and  Treatment  Groups 


Question  # 

Pre-Test 

Post-Test 

Pre-Test 

Post-Test 

1 

0.18 

0.19 

0.28 

0.59 

2 

0.75 

0.73 

0.84 

0.73 

3 

0.58 

0.30 

0.60 

0.73 

4 

0.67 

0.66 

0.44 

0.73 

5 

0.67 

0.71 

0.44 

0.55 

6 

0.42 

0.52 

0.44 

0.50 

7 

0.50 

0.52 

0.68 

0.68 

8 

0.58 

0.65 

0.64 

0.68 

9 

0.75 

0.77 

0.56 

0.59 

Mean 

0.57 

0.56 

0.55 

0.64 

StDev 

0.18 

0.20 

0.17 

0.09 

Df=12 

Student  t  =  0.11 

Student  t  =  -1 .40 

p-value  =  0.54 

p-value  =  0.09 

Neither  group  achieved  significance.  However,  the  large  difference  hi  p  value 
betw  een  the  control  and  the  treatment  group  would  indicate  that  the  SQUARE 
treatment  provided  a  considerable  increase  in  security  knowledge.  One  explana¬ 
tion  for  the  fact  that  the  treatment  did  not  quite  achieve  significance  was  the  fact 
that  both  groups  w  ere  composed  of  advanced  software  engineering  students  and 
as  a  result  it  is  likely  that  both  groups  had  inherent  awrareness  of  security  topics. 

As  an  additional  test  of  the  effectiveness  of  the  SQUARE  treatment,  the  stu¬ 
dent’s  end  of  term  project  deliverables  w  ere  subjected  to  a  qualitative  analysis  by 
the  instructor.  The  instructor  has  taught  this  same  course  for  the  past  seven  years. 
It  was  found  that  the  quality  of  the  student’s  project  deliverables  increased  gr  eat¬ 
ly.  The  use-case  model  and  the  analysis  model  for  the  semester  model  addressed 
security  requirements  and  risk  in  a  way  that  wras  far  superior  to  other  semesters. 
Additionally,  the  students  were  able  to  achieve  these  results  with  less  interven¬ 
tion  and  help  from  the  instructor. 


PRACTICAL  IMPLICATIONS  AND  FUTURE  PLANS 

It’s  easy  to  see  that  this  idea  could  be  extended  to  include  software  engineering 
practices  that  focus  on  developing  secure  software.  Although  these  are  early  re¬ 
sults,  based  on  two  cases,  when  students  learn  about  security  requirements  engi- 
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neering  and  SQUARE,  they  have  a  better  understanding  of  what  is  needed  to 
produce  more  secure  software.  That  finding  is  potentially  important  to  the  field 
of  software  engineering.  As  such,  the  validated  SQUARE  model  could  prove 
both  highly  useful  to  the  profession  as  well  as  potentially  very  influential  in  the 
teaching  of  security  requirements  engineering  practice.  It’s  easy  to  see  that  this 
idea  could  be  extended  to  include  software  engineering  practices  that  focus  on 
developing  secure  software. 

As  experience  with  these  approaches  grows,  our  plans  include  the  gathering  of 
more  quantitative  data  to  show  the  benefit  of  the  approach  we  have  discussed 
here.  So  far  there  have  been  some  300  downloads  of  the  SQUARE  educational 
material  from  the  CERT  website.  One  of  our  goals  this  year  is  to  conduct  a  sur¬ 
vey  to  find  out  about  the  usage  of  the  material  and  its  results.  It  is  our  hope  that 
in  the  future  there  will  be  more  synergy  between  software  assurance  and  soft¬ 
ware  engineering  education.  Other  universities  around  the  world  offer  courses 
and  lectures  that  include  methods  for  developing  secure  software.  If  those  uni¬ 
versities  conduct  similar  studies,  we  expect  to  see  additional  results.  For  exam¬ 
ple,  SQUARE  educational  material  was  translated  into  Chinese  and  delivered  at 
National  Defence  University  in  Taiwan.  Feedback  from  this  offering  is  forth¬ 
coming.  If  more  universities  incorporate  the  content  of  the  4  SQUARE  lectures 
into  their  course  offerings,  we  hope  to  strengthen  the  results  presented  here. 
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